From Simple Software Company....................producers of SlickWare ! Telecommunications for the Beginner by G.M. Raymond Welcome to the world of Slick Communications. This tutorial is intended for the new telecommunicator who is interested in learning about the world of modem and computer communications. Perhaps you have already heard about modem telecommunications and just want more information. This article will tend to serve the needs of either person. Your first question may be "Just what is a Modem good for?" The most common use is to access other computers. This could be to exchange data with other computers within a company or to access computers of other individuals or companies. This computer connection can be made via an ordinary telephone system or on a special leased line or network. Perhaps the most ordinary use today for individuals, is to use their modem to call other private or commercial systems, known as BBS's (short for Bulletin Board Systems). These BBS's provide a place for program writers to market their products (called ShareWare) and an electronic mail forum for messages, questions, and anything of interest to telecommunicators. Most people elect to download programs. We will talk more about that later. First, lets get a handle on terms and definitions. To communicate via voice, be it wire or radio, it is necessary to MOdulate our voice signal onto the electrical current carried by wire or radio wave. Then, on the receiving end, DEModulate the current back into intelligent audible sound waves. Essentially we do the same thing with a computer. We take data and send it out and reinterpret it on the received end. So, this is the job of the MODEM. The humble modem is actually a very sophisticated piece of electronics-. Just as standardization took hold of broadcasting, with AM and FM dominating the available channels today; there has been a slow but consistent push to standardize the methods of exchanging data between computer modems. First, you should understand that the modem, like the computer itself, is just a dumb machine. It too (the modem) need a soft-ware program to operate. These are generally referred to as Terminal programs or comm software. Naturally, we are partial to SLICK terminal because we sell it. Fortunately, most all modems still being manufactured today, use a set of instructions called Hayse commands which have more or less become the industry standard. Most all modems and software found on todays market will have the necessary configurability to adjust to each other as well as the computer. We need to talk about this more. Your modem will connect to your computer via a connection referenced as a serial port. It might be interesting at this point to state that any external peripherals (printers, modems, monitors) will usually attach to either a serial or parallel interconnection. The basic difference between the two methods lies in how the signal is moved through the cable. In a serial connection, each bit of data is sent sequentially (that is, one after another). It takes 8 bits of data to represent a single character of which there are 256 (including 0) characters in the IBM ASCII set, or, 7 bits for any character below ascii number 128. The alphabet and most common punctuations are in the range of decimal 33 to decimal 127. So, with a serial connection, 7 or 8 signals must pass to have one character arrive on the other end. By comparison, with a parallel connection, all 7 or 8 bits are sent together on eight separate wires in the cable. With this system, each character arrives intact and almost eight times faster. The parallel method is ideal for supplying devices like printers with input data because of its speed. The biggest drawback is signal attenuation when trying to use long cables (i.e.,stay under 12 feet) and finding accurate method of error checking the integrity of the data sent. (i.e. did a character Z actually arrive as a "Z"). Sending data serially has certain drawbacks when it comes to this error checking procedure. Several methods have been developed that have become standards. If you are only interested in sending the alphabet, you do not need the full byte or all eight bits, remember, seven will do nicely. This is because the dec value of 127 in binary form is 0111-1111, requiring only 7 bit positions. Starting from right to left, each of these bits represents a decimal value of 1,2,4,8,16,32, and 64. The sum of these bits equals 127. If the left most bit were to be used (1111-1111), its value alone equals 128 so by using 8 bits all 255 characters could be encoded and transmitted. That is, a range of values from zero (0) to 255. (Yes, zero has a value). The bottom line, 7 bit rate transfers are faster but useful only for text data. (sometimes referred to as low ascii- [under 128]). On the other hand, the eighth bit can be useful for parity checking which we will discuss later. If we were to actually use the 8th bit for character data this would eliminate parity verification. Hence a setting of 7E1 is useful for character (English text) only. This also precludes a setting of 8E1 or 8E2. Yes, the 7 is the number of data bits used, the E, O or N indicates the use of parity or NO parity. The one (1) is for the number stop & start bits. There are some technical exceptions to all this but it is not important to discuss it here in order for you to generalize the grits of the matter. EXE Files are made up of ascii characters throughout the entire ascii range of zero through 255. (yes, zero is a value to be counted....in fact the computer could not survive without it). Just to be safe then with only a small sacrifice in speed, 8 data bits is the way to go. The next consideration is also one of protocol. Do we use 1 or 2 extra bits to signal the start or stopping point of the group of 8. There is an argument that can be made that two are more reliable than one but it also can be said the loss in double the transmitting time isn't worth the extra margin of accuracy. By preference, most choose only 1 stopbit for their protocol. Now we have to talk about parity. This is nothing more than a simple way of testing each character for accuracy on the receiving end. There can be either EVEN, ODD or NO parity. Parity is simply a checking of the transmitted bits per byte (character) to determine if the seven positions make up an odd or even number. A zero is used as the eight bit if the other seven result in an ODD number of ones and a 1 (one) is used to indicate an even number. i.e. 01000001 (normal capitol A) becomes 11000001, when parity is set to ODD. The reverse is true for EVEN Parity. (0 means even) Parity checking is not only time consuming but also inefficient. It is rarely used today on anything but older DEC mainframes. Finally, we arrive at 8-N-1. Eight bits, No parity, and 1 stopbit as the desired order of doing business. The IBM Personal Computer or clone has various internal addresses for its four normally available serial ports. We reference these as COM1,2,3 & 4 but this is not in-fact the actual location pointer required by the hardware. $3F8,$2F8,$3E8 and $2E8 are the correct locations for these ports as defined in their hexadecimal format. (a number system using a base of 16 to represent larger decimal values in smaller numbers of bytes, i.e. 65,535 is equal to FFFFh [a two byte value]). Next, you must determine what Interrupt Request line is to be used internally with each comm port. The usual arrangement for COM1 is address 3F8h and IRQ4; COM2/2F8h/IRQ3. Seldom will you use more than two comm ports on a system although it is not out of the realm of possibility. It really doesn't matter what port address you use on a modem until you begin to use other serial port devices like a mouse or null modem connection (to link up two CPU's by cable). With more than one serial connection, it is sometimes important what device goes on what port as well as having them properly addressed in order for everything to work together smoothly. A good modem will have either switches or jumper pins for you to tell it what comm address it is looking for and with what interrupt. There is also a redundant process here because you must also configure the software to operate with the same settings. Probably the biggest headache of all is setting the software to tell the modem via attention commands (AT), what it needs to know to perform the required tasks. In most cases, this is done all at once via something called a modem initialization string that begins with AT. All modems will initialize with a pre set factory designed default setting. Very often it happens that a good modem will default to all the correct settings on its own and you are just wasting your time re coding an initialization string that will only repeat for a second time the built in factory settings. Here, several of the more important registers to think about are the CD and DTR registers. Normally you want software control over these and NOT have them forced on by either dip switch or jumper settings. Most all troubles related to problems with hanging up or auto-answer can be traced to the MCR register. If your modem defaults to &C1 and &D2, great. If not, you need to set them. (via the hardware if able and or software modem initialization string.) Here are some other recommended settings and what they accomplish. M1 ..... Speaker On for Dial,Carrier Detect,HandShake and Result Code, then off as DATA begins. V1 ..... Verbal Result Codes (examp: CONNECT 2400 rather than a "3") X4 ..... Show All available Result Codes E0 ..... NO local modem Echo of characters. (The host does this) &C1 .... Software control of Carrier Detect Status &D2 .... Software control of Data Terminal Ready [MCR] register S7 ..... DTMF (touch tone) dialing speed (usually 70ms aprox is ok) S0=x.... set this to 0 to prevent your modem from answering your phone line or x to the number of rings before pickup. This will give you a good idea but please remember, when all else fails, read the modem manual. It might be a good point now to bring up another related subject. Most computers will not respond to the high order graphics and ANSI color signals without the ANSI device driver, (found in the DOS diskette) called ANSI.SYS. ANSI can be loaded via a statement in the computer CONFIG.SYS file. The added line to the SYS file is simply DEVICE=C:\PATH\ANSI.SYS. Of course substitute PATH for the actual directory path to the location of the ANSI.SYS file. This will allow monochrome systems to receive ANSI graphics and at least see the graphics if not the color, and color systems to come alive with ANSI color and animation. My hats off to the guys who can write good quality ansi graphics for they are truly artist as well as programmers. It might also be wise to mention that the only difference between an internal modem and an external one is the price. There is little advantage in my mind in using external modems. Aside from their cost increase due to the necessity of having a built in power supply plus an external case they are more apt to both receive interference (due to poorly shielded cables) as well as generate RFI. Since most PC have at least two or three expansion slots left over after over zealous purchasing, there is usually plenty of room inside the computer case to install the modem. This is usually nothing more than slipping the card snuggle into an available slot and using one screw to secure it in place. There are usually two modular jacks on the back, the upper one for cabling to the phone line source and the second for plugging in a regular phone for whatever use you may have of it. Assuming all has gone well at this point you are ready to boot up the computer and run the software. Most all terminal programs first clear all registers back to default status with the universal ATZ command, then send the required initialization string for the subject modem. Unfortunately a lot of programs either blank the screen during this process or simply don't allow the string to appear on screen in this phase. I am against this kind of design because you never know if the modem swallowed the string without rejecting it. Meaning, accepted it fully and set registers accordingly or returned an ERROR rather than a friendly "Ok" reply. The error always indicates that one or more of the commands in the modem string is incorrect for that modem. This means its hardware controllable only (Dip Switches,etc) or not an option of that brand of modem. If just ONE command is at fault, the entire string is rejected. Most modems will accept up to but not exceeding 40 bytes or characters in the command string. If you are preparing to buy a modem for the first time, be careful. Like any products, there are good ones and buggy one. Sticking with Brand names usually is best and although most modems are being made overseas, there are several US and Canadian companies making superb products. If you want the latest state of the art, look for a modem that supports the newest hardware error checking and compression technique called MNP-5 (for Micro Comm Network Protocol, level 5). Finally, if you can afford it, there are several high speed modems around that run at 9600 baud or better. The high speed models almost always work at all the lower standard speeds as well. But, in any case, don't buy anything below 2400 baud. I say this because the price may be tempting as there are companies selling older 300/1200 baud rigs for well under twenty bucks. So what DOES modem speed have to do with anything? Well, if your one of those folks fond of quoting "Time is Money" you can certainly save a lot with a faster modem. Let's see what happens here. First of all, what is a baud or baud rate? Its the number of BITS per second capable of being transmitted. Now, if an average sheet of paper is 80 columns across and 66 lines deep this counts out to exactly 5280 characters per page if completely filled. Now remember, each character may require 7 or 8 bits to construct. Then we need the extra stop bit, parity bits if any and framing bits. We might end up with as many as five additional bits per character by the time they are formatted for transmission. So, for argument sake, use the value 12 bits X 5280 characters. This is 63,360 bits. If we send them at the rate of 300 baud this will take (63360/300) seconds. Or about 210 seconds (3 and one half minutes). At 1200baud it's four times faster or only 52 seconds. At the 2400 baud rate we half this down to around 25 seconds. Since an average text page is really only half the maximum characters available this means in one minute at 2400 baud you could transmit four normal business letters. Since AT&T is not free and they have both minimum and time based rates on toll calls, there is no question that under some situations a high speed modem could easily pay for itself. The average size programs today run between 30 and 70k. (each k equals 1024 bytes). Most good modems running at 2400 baud will average about 4 seconds per k. Why did I use the word average? Well first of all, I left out a lot of detail that might have technocrats pulling out their hair. In any case, its neither my ability or intention to get too technical here but since were into speed somewhat as a subject of exploration, let's talk about SLOWDOWNS. Remember earlier we discussed a parity check at the byte level for catching errors? We said that in most cases it was no longer used. Well, the reason for that is due in part to more elegant ways of catching errors. Probably the first and simplest of all methods is the CHECKSUM. Remember, the setting of each one of the eight bits of a byte (zeros or ones) determine its decimal (and character) value up to 255. So, every byte has a decimal value as well as a character value. (i.e. capital A is decimal 65). With two bytes we can carry a decimal value up to 65k. This means we could sum the value of 255 characters and send the total in two bytes of data. If the sum on the received end is not the same as the previously sent checksum value, the packet is rejected with a NAK and a request for re transmitting is made. By limiting the packet size to 128 bytes, shorter transitions of interference (line noise, etc) wont cause bigger delays due to re transmitting of large packets. This gives rise to a common mistaken idea that while monitoring a download, and errors are reported by the protocol software, that the file is corrupted. No, it only means that for every error it cost you more time to receive the same packet without error by re transmitting. In any case, CHECKSUM was how it began and IT'S STILL HERE. I guess that speaks for its staying power. But, like everything, it has been greatly improved upon. Now Cyclic Redundant Checking, or simply CRC protocols are the rage. Its more difficult to explain in simple terms but the bottom line is a CRC value is calculated for each packet transmitted and compared with what is calculated on the received end. Again the two must agree. The accuracy derived from CRC methods lies in its ability to pass every bit through a 16 (or 32) bit shift register that does an Exclusive OR with the 6th,8th,11th and 15th bit of the 16 bit register. Each bit causes the value of the register (which can be expressed in four hex numbers) to change to a new value. By the time the last bit is processed a number is derived that represents a CRC value for the ordered group. This method is almost infallible. The method was originally developed to test the accuracy of the bit content (program) stored in the ROM's of the PC. Programmers specializing in writing transfer protocols soon began to incorporate it into their creations. Now, its used almost exclusively. There are several ways to ask a modem to dial a number for you. You can do it manually or call a number from a previously created dialing directory that is accessed by the software. To do it by hand simply type ATDT followed by the number if you have Touch Tone Service. Or ATDP for pulse dial. The string will look like this: ATDT288-6550 (note, the modem ignores the hyphen). Or, if it's long distance....ATDT1-504-288-6550. Suppose you wish to defeat Call Waiting for this call only (if left on, it can cause trouble), the string is ATDT*70,288-6550. *70 is the AT&T temporary disable wait instruction, the comma is a modem 3 second delay command before continuing with the dial. (this allows time for the command to be received and for AT&T to give back a dial tone). After entering your dial string you should hear the modem taking the line off hook (signaled by the appearance of the dial tone in the speaker), the DTMF dial pulses going out, the ring or busy tone at the destination number followed by the host modem answer tone and handshake, followed by a CONNECT message on your screen. The standard for a plain CONNECT is a 300 baud logon. CONNECT 1200 and CONNECT 2400 are self explanatory. Some host systems require a few carriage returns before you will see anything on the screen but most will automatically begin displaying after the connect message. Most of the people who operate BBS's are hobbyist. Running a BBS represents a form of hobby and social activity all rolled into one, similar in a lot of ways, to ham radio. Few Boards will give you total, immediate access to everything, but there are some exceptions. Most will request your real first and last name, a local phone and address, (or out of state,if that be the case). Some SysOp's or SYStem OPerators, (the guy who owns or manages the Board) will even phone you to verify your existence. Other sysop's have even more stringent requirements, but, most will simply give you access next time they sit at the console and get caught up with their duties. (usually within 24 to 48 hours). When BBS's first cranked up in the late seventies, Sysop's were sort of groping along trying new and innovative ideas. The first BBS'es were, in fact, nothing more than message (hence Bulletin) boards. The BBS concept was so new, the use of phoney names and cloaked identity was very common. The misuse of BBS's for a while even threatened their legality, as so called hackers exchanged ideas and information they gathered. Most of this was in the form of either passwords to big mainframes, private telephone access code numbers and pirated software. Fortunately, BBS's have grown up and matured into very legitimate forums of information exchange. To this day I still do not have a clear understanding of the word Hacker. It seems to mean many things depending on who you are talking to. Few Sysop's run Bulletin Boards that they authored. They usually use a favorite commercial product that seems to best fit their own idea of what a Board should do. Sometimes new SysOps fall victim to the advice of a so called master sysop or seasoned user. If nothing else, one thing you will learn quickly in this business is that there are a great deal of self proclaimed computer consultants. What's really funny is the true complicity of the machines vrs the real depth of knowledge of most of these so called consultants. I think the old saying "A little knowledge is dangerous..." is most appropriate. Many of the silly dumb questions that come fourth when attempting registration on a BBS are a the creative genus (or madness) of the Sysop or the author of the BBS program. One of my personal gripes is the Sex and Age questions; why not race too, and make it a total violation of first amendments rights. Anyway, like it or not, you have to comply with the SysOps rules if you expect to gain access to his system. Most Boards allow some limited ability on first Logon, like reading the Bulletins and E-Mail (Electronic Mail). A Menu will appear giving you the choices available. It is well known among seasoned Sysop's that 99% of all registered users only check in to see what's new in the Files Directories. Some BBS automatically advise what new files have arrived at time of initial Logon. Some Sysop's have the mistaken notion that running a BBS can be a neat way to accumulate a lot of good software. It really works in the other direction. A good Sysop will have access to files long before his local users will. He quickly realizes it is he who will ALWAYS be providing the latest files and not his users. For this reason I suggest steering away from any Boards that demand certain Upload/Down load ratios (what you contribute vrs what you take). In any case, most contributors cause more problems than they cure. They will repackage (re archive or compress a file under an altered name) in order to re transmit it for credit. Sometimes they leave important things out that could be grounds for license violations of the software. Then there is the Virus thing. Although at this point I see NO PROBLEMS AT ALL in this area, the potential is there. Perhaps for curiosity sake a few definitions might be in order. There are usually three adjectives tossed about; Virus, Worm & Trojan. Each has a separate but similar meaning with some crossover effects. Basically, a Virus is a segment of code that is capable of altering your operating system code (like COMMAND.COM) in such a way as to cause the virus code to be written into any files you transfer to floppy either via the operating system or the executable files themselves. This replicates the code (like a virus multiplying) onto disks that may ultimately infect other machines. The code theoretically could be constructed to remain dormant until a certain system date comes up or after the machine is booted so many times. Then it could pop its ugly head and cause all kinds of trouble. Possibilities are a reformat of your hard drives, a crippling slowing down of the CPU clock cycle, altering Interrupt vectors causing system crashes, locking the CPU into a constant reboot cycle....the list is endless. A Worm is identical to a Virus in damage possibilities but its not intended to be passed on or replicate itself. A Trojan file is, in my opinion, the worst possible threat. This is a program that sells itself as a game or utility while in fact is purely intended to cause harm to your system. Why is it so dangerous as compared to a Virus or Worm? It has to do with Intelligence itself. The kind of PhD education, experience and training it would take to write an effective Virus or Worm generally would ethically and morally preclude the creator from doing it in the first place. He would in reality have to be off balance and suffering severe mental and emotional distress to conceive of this as entertainment. In any case there are perhaps less than a few dozen minds in the country who are even capable. BUT, the Trojan is a different story. First, almost any self taught programmer could, via the readily available high speed compilers available today in any software store, write a simple trojan. It might start by playing music, let's say, while using that to mask the sound of your hard drive reformatting! It would not take much creativity to come up with an idea and write the code for it. Anyone familiar with Pascal or "C" could do it. For that matter it could be done in BASIC. Well, "What can be done?" you ask. Actually a lot if you are willing to take the effort. Keep a virgin copy of COMMAND.COM locked away on a diskette with a known good copy of the two hidden system files. Use a CRC checking Utility to determine the CRC value of the original copies, including their exact byte length. The man who could alter a file, imbed a Virus, and do it in such a way as not to effect the CRC and byte length of the file just doesn't exist because that'd almost impossible. (yea, I did say almost). Also, just as every criminal act must have a motive, no hacker would take the time unless he could get some kind of ego trip going. Once he bit your hand it would be meaningless unless he got to inform you that you were a sucker and have been had! To do this he would probably have an ASCII message in the code to that effect. There are many utilities capable of scanning an executable file for hidden messages. There are also a number of utilities that are capable of searching through an executable file for calls to certain DOS Interrupts that would be necessary to play havoc with the central processor or mass storage devices (hard drives, tapes, etc). Right now, in my opinion, this whole business of Virus etc. is more a question of knowledge and preparation rather than a current reality. Cuba could send a strike force up the Mississippi to invade the US via New Orleans. There are even occasional reports of vessels at the mouth of the river. What does reason and logic say about this? One real tragedy of human nature involving personal computers is the user who either unknowingly or while engaged in experimentation, trashes his hard drive or corrupts his files; and, rather than accept personal responsibility, claims foul Viruses did him in. Sort of like a modern version of "Crying Wolf". Its been done so often, will we believe it if it ever actually does begin to happen? Now lets talk about archived files. An archived file is rather like a suitcase. A repository or collection of a number of separate items, organized or placed in such a matter as to make retrieval quick and easy. There is one special difference however. Archived files are compressed to their minimum possible size before being stored in the archive or suitcase. This compression technique can be based on a number of possible algorithms or compression formulas. The first clue is the extension of a file. Here are several very common ones: .ARC, .PAK, .ZIP, .LIB, .ZOO. Generally these are not compatible methods and each requires its own special utility (work program) to compress and un-compress. There is another method, gaining popularity, called suitcase files which have the .EXE extension. When executed, they immediately begin spawning many additional files that come from within the main suitcase file itself. They are automatically uncompressed as they are re-written back to disk by instruction or programming from within the suitcase. Since they look like any other executable file it is sometimes difficult for the inexperienced to tell them apart from ordinary run time programs. There is a trend developing, due mostly to the influence of BBS's, to standardize the algorithm's (formulas) used to archive. There is to this day no clear cut winner. However, ZIP files (for being Zippered up) are showing up everywhere, perhaps becoming the dominate method. Time will tell. In the meanwhile, it can't hurt to begin collecting the top four or five Compression utilities. Then, no matter what you encounter, you will be prepared. Most all good BBS's carry them all in the Archive/ Compression directory of their Files department. Aside from going with the flow, things to consider if you have a lot of personal need for storing files are: The speed of both compressing and un-compressing, (remember, time is money); the degree or % of compression (how much space are you really saving); ease of use; extra utilities (i.e. the ability to password protect, etc etc); registration cost; support if you need it; and suit-casing ability. I like features I find in each of the popular methods but, again, due to BBS impact, find myself working most often with Zippered files. Now its time to talk about how to get the files to your end of the computer, (down loading), then we will discuss the opposite situation, contributing a file to someone else's system (up loading). As with most situations there is sort of a convention of thought when it comes to the keys used to manipulate a terminal communications program. Normally, PgUp and PgDn bring the upload or download menu into view. Lets start first with down loading. Assuming you found your way into the Files section of a BBS and had opportunity to request a display of all (N)ew files since your last visit (or perhaps you used the BBS searching utility to determine if what you want is present) your next step is to request a (D)ownload. Some BBS require that you be within the specific file directory that the file is located before starting, some will allow a download from any location within the files section. As soon as you request a download, the BBS will usually first ask for the protocol name (method of sending the file which must be the same on both ends). Some BBS have your preference protocol as a default. (a protocol you requested on initial registration). Then, the name of the file is requested. If you type it in wrong or its really not there, the BBS usually informs you. Otherwise you get a message to continue on your end. You don't have all-day to reply to prompts, usually 60 seconds or less. Here is where you hit PgDn on your end. Depending on the protocol selected you may or may not have to retype the file name on your end BUT you must pick the SAME protocol. From here on, the process is rather automatic and you can usually go about some other duties in the room until it beeps that its finished. The file will either be deposited into your default directory or if the comm program allows, wherever you instructed it to go. Let's talk about protocols for a moment. The common ones are Ascii, Xmodem, Ymodem and Zmodem. Most everything else is variations of these such as Clink, Mlink, Jmodem, Lynx, etc etc. Its true that a few protocols are inter-compatible but if you go by the rule of sameness for BOTH ends, you can't go wrong. Some protocols allow the selection of multiple filename's for transfer such as Ymodem/Batch and Zmodem. My own preference is Ymodem/Zmodem when available. Zmodem has a few intelligent features, that under some trying circumstances, could be handy. It has the ability to reduce or increase packet size depending on quality of transmission conditions. It also has a crash recovery mode. Meaning, if you lost connection halfway through a file transfer, you could reconnect and pick up where you left off (without repeating the entire file). On the other side of the coin there are still a large number of systems using only Xmodem and Kermit. Kermit is a protocol used when a personal computer has to exchange data with a big main frame. Its seldom ever used PC to PC. Because of computer design, storage design etc. packet sizes can vary from 128 bytes of data too several k. Sizes of 1k (1024bytes) are the more common. The only real reason for limiting size is quality of transmission medium. If a transmission medium is 100% capable, there really be no need to limit packet sizes. On clean systems, Jmodem is popular because of its ability to run up to 8k packets. This saves a small amount of time but in my opinion not worth the risk of some corrupted bytes getting through. (a byte whose value has been altered from its original value by a change in one or more of its 8 bits) If you desire, you can obtain services on Telephone Network systems that are, on average, cheeper than regular long distance services. US Sprint has PcPursuit on the Telenet System that cost $1.00 per hour for the first 30 hours of time. Yes, there are a few hooks. You pay a 30 buck monthly fee regardless of the minimum time used and are limited to perhaps only 40 or less cities. Still, considering AT&T at $6+ per hour this can save money. Slick has a special set of built in Macros to make logging on to Telenet's PcPursuit service an easy process. Lets talk now about some simple rules of BBS etiquette. First, never drop carrier (hang up) when you are finished. Take the time to leave via the proper exit (Goodby or Off key). Dropping carrier is the equivalent of having a guest suddenly leave your home and SLAM the door on the way out. Second, don't POST (leave messages) in ALL Capitol Letters. This is the equivalent to shouting in someone's face. Third, if you are going to use someone's else's BBS, operate according to his rules. If you don't like the rules, go some-where else where the rules are more to your liking. Finally, be cautious. If you are intent on pranks you should be aware that most ALL forms of communication are supervised and protected by federal laws. Its easy to get caught when on a phone system today as everything is a matter of record. With ESS offices, the system can log/trace anything, anytime it's necessary. EOF